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ENCRyPti 

more than just 
complex algorithms 



MUCH OF THE INFORMATION 
AVAILABLE ON ENCRYPTION 
FOCUSES ON THE MATH BEHIND 
TRANSFORMING DATA OR 
CREATING KEYS. ENCRYPTION, 
HOWEVER, IS ONLY ONE PART 
OF A COMPREHENSIVE PROTEC- 
TION SCHEME. JUST AS IMPOR- 
TANT AS A STRONG ALGORITHM 
IS A SECURE IMPLEMENTATION 
OF THAT ALGORITHM. 



THE RISE OF DIGITAL TECHNOLOGY HAS CHANGED the Way peo- 
ple use and store information. As more and more data takes a 
digital form — shifting from physical media, such as film, tape, or 
paper, to bits — the need to protect both the content and the priva- 



cy of information has increased. For ex- 
ample, music and video copied from a 
digital versatile disk (DVD) results in a 
perfect copy, a factor that has held up the 
adoption of DVD because studios are 
afraid to leave their valuable content so 
vulnerable to theft. 

Encryption technology plays an im- 
portant role in maintaining the general 
availability of information and control- 
ling its use and abuse. Only those indi- 
viduals with access to the proper key can 



read encrypted data. An electronic crack- 
er trying to break an algorithm with a 56- 
bit key needs to try random keys from a 
key space of "£* keys. Depending on the 
speed of the processors that crackers use, 
cracking can take hours to centuries. In 
general, the larger the key space, the 
stronger the algorithm. 

The perception that encryption 
strength depends wholly on the encryp- 
tion algorithm is false. Given the large key 
spaces and complexity of today's encryp- 
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tion algorithms, breaking the algorithm 
is the last place an attacker attempts to 
compromise a system. Strong encryption 
can protect information, but only if the 
"box" housing the encryption is at least 
as strong; for example, if an attacker can 
access information before the system en- 
crypts it, then there is no need to break 
the encryption algorithm. No product is 
an island, especially when it comes to se- 
curity. You may build the part of a system 
that actually employs encryption tech- 
nology, but the rest of the system — if sys- 
tem manufacturers don't take care — can 
nullify your hard work: Security is only 
as strong as its weakest link. Additional- 
ly, the more complex the system, the 
more potentially vulnerable it is to attack. 

You should consider several important 
factors to successfully implement en- 
cryption and reduce system vulnerabili- 
ties. These factors include selecting an al- 
gorithm; securely implementing en- 
cryption; managing keys; and balancing 
performance, price, and privacy to 
achieve sufficient security. 

With a complete understanding of se- 
curity and encryption issues, you can be- 
gin to compensate for potential vulnera- 
bilities in other parts of a system or point 
them out to the engineering teams de- 
signing these systems. System issues may 
include guaranteeing the integrity of data 
from unauthorized tampering, such as 
insertion, alteration, destruction, and re- 
play. Another issue is guaranteeing con- 
fidentiality and privacy. It may be im- 
portant to protect information flow and 
content from disclosure. (For example, 
viewers may want to keep private the 
kinds of movies they watch.) Guarantee- 
ing authentication is yet another issue: All 
parties are who they say they are, and 
only authorized parties have access to in- 
formation. Repudiation is also a factor. 
Transactions are immune to 
false denial (for example, "1 j 
never ordered that") 
through proof of 



Figure 1 



origin and delivery. Finally, 
consider restoration: A system 
and its information can survive 
and resume service after an at- 
tack (for example, a set-top 
prepay procedure is broken). 

NEW STANDARDS FOR OLD 

A multitude of encryption 
algorithms and protocols is 



AT A GLANCE 

> Sufficient security is a balance of price, 
performance, and privacy. 



i>An application may require several en- 
cryption algorithms working together to 
guarantee data integrity and authenticity. 

o Encryption technology is available 
as software, ICs, or embedded cores. 



t> Biometrics and tokens, such as smart 
cards, protect keys from misuse and 
unauthorized copying. 



i>The more complex the system, the more 
vulnerable it is to attack. 



available, depending on your application 
and the required level of security (Table 
1). For some applications, formal or de 
facto standards exist, including the Data 
Encryption Standard (DBS) for financial 
transactions, the secure-sockets layer for 
networks, and the Internet Protocol Se- 
curity Protocol (IPSEC) and Secure/Mul- 
tipurpose Internet Mail Extensions 
(S/MIME) for the Internet. Several mes- 
sage-authentication, or "hash," standards 
also exist, such as Secure Hash Algorithm 
(SHA-1) and message-digest 5 (i\'ID5), 
which produce a fixed-length value guar- 
anteeing the integrity of a message and 
which an attacker cannot use to derive the 
original message. Many of the standards, 
such as S/MIME, are protocol definitions 
based on base encryption algorithms, 
such as DES, Triple-DES, and RC2 
(Rivest's Cipher). 

By far, the most widely used algorithm 
is DES, employing a 56-bit key on a 64- 
bit data block. It is possible, however, for 
a cracker to break a DES cipher in less 
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Using symmetric encryption, both the sender and the receiver use the 
same secret key. Exchanging the secret key requires a secure channel. 



than a few hours (Reference 1). The issue 
is not whether a cracker can break DES 
56-bit keys by brute force but how cheap- 
ly it can do so. 

Industry insiders are already taking 
steps to replace 56-bit DES with an algo- 
rithm using a larger key space. The Ad- 
vanced Encryption Standard (AES) is the 
official successor to DES, but it won't be 
available until 2001. Until then, the Na- 
tional Institute of Standards and Tech- 
nology (NIST) recommends the use of 
Triple-DES, or ANSI standard X9.52. 
Triple-DES churns a message through a 
DES engine three times. The standard of- 
fers several modes supporting three keys 
per transaction, as opposed to one, and 
alternates encryption and decryption. 

In addition to standard algorithms 
such as DES, many proprietary schemes 
offering varying levels of strength, such 
as elliptic curve and dynamic substitu- 
tion devices, are available. The difference 
among these algorithms is their mathe- 
matical bases: DES uses S boxes, public- 
key encryption uses large prime num- 
bers, and several of the next-generation 
algorithms use modified Feistel net- 
works. Unless you plan to code an algo- 
rithm yourself, you need not dive into the 
details of each algorithm type (Reference 
2). The key difference in schemes is the 
varying processor and memory require- 
ments for implementing the scheme. 
DES has been successful because of the 
small cryptoengine necessary to manip- 
ulate 56-bit keys. A 1024-bit key algo- 
rithm offers greater security but requires 
significantly more processing power. In 
any case, be wary of vendor claims and 
benchmarks. For example, you may hear 
that a 160-bit elliptic key is equivalent to 
a 1024-bit RSA (Rivest, Shamir, and Adel- 
man) key. Be sure to ask for concrete ver- 
ification of such claims and ask competi- 
tors for their takes on such 
claims. 

The open/proprietary is- 
sue takes a different angle 
with encryption technolo- 
gies. Certainly, you can prove 
an algorithm weak by break- 
ing it, but no known means 
exists for proving an algo- 
rithm secure. With the tools 
for reverse engineering, re- 
liance on the "secret" proper- 
ties of an algorithm is little 
security. Thus, there is some- 
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thing to be said for the rationale that an 
algorithm should be strong enough so 
that publishing it does not weaken it. In 
general, confidence in an algorithm in- 
creases with time, given that none of the 
experts of the day can crack it. New al- 
gorithms often do not have the scrutiny 
that old algorithms had. 

You can take a hard look at the next- 
generation algorithms, such as Twofish, 
RC6, and Cast-256, competing to replace 
today's "obsolete" standards by reviewing 
the work that NIST is doing on AES. 
NIST is running benchmarks for each of 
the algorithms under various operating 
conditions, as well as gathering qualita- 
tive comments from the encryption 
community (Reference 2). Those algo- 
rithms that NIST does not choose to be- 
come AES will still be available, For ex- 
ample, if you control both ends of the 
communication and do not need to in- 
teract with any outside network, you 
have complete freedom to choose the 
most appropriate algorithm, based on 
the required level of security, perform- 
ance, throughput, cost, and size of your 
pipeline in both directions. You are not 
bound by NIST's choice of algorithm 
and can select the best algorithm for your 
system needs. 

In any case, DES will be around for at 
least as long as legacy systems require 
compatible support. There is already ex- 
tensive investment in DES, which will 
probably for some time color the evalua- 



tion of how DES adequately meets needs. 

If short keys have "killed" DES, why 
not just use extremely large keys to be- 
gin with and evade the issue of ever 
cracking an algorithm? The trade-off is 
balancing performance, price, and priva- 
cy. Algorithms such as RSA can employ 
long 1024-bit keys and processor-inten- 
sive algorithms, effectively making the 
possibility of cracking a message zero. 
Long keys and complex math, however, 
though they offer more strength and se- 
curity, require significant processing time 
(even minutes), making them infeasible 
for bulk encryption. One option is to use 
both kinds of encryption together. 

Algorithms such as DES are symmet- 
ric, or synchronous, algorithms: Both the 
sender and the receiver use the same se- 
cret key (Figure 1). Symmetric algo- 
rithms employ transposition and substi- 
tution, operations that many processors 
handle quickly. Asymmetric, or asyn- 
chronous, algorithms, such as RSA, on 
the other hand, use a private key that only 
the owner of the key knows and a public 
key that others use to communicate with 
the owner (Figure 2). Because one of the 
keys is public, there is no need to have a 
secure channel over which to share the se- 
cret key of a symmetric algorithm. (If you 
have such a secure channel, why not just 
send the message?) Asymmetric algo- 
rithms, such as those based on prime 
numbers, require multiplication, which 
tends to significantly slow processing. 



Asymmetric algorithms also use much 
longer keys (greater than 400 bits). 

A hybrid option uses both kinds of al- 
gorithms, employing a "digital signature" 
(Figure 3). Using a symmetric key, the 
sender encrypts the message more quick- 
ly than he could with an asymmetric key. 
The sender then encrypts the symmetric 
key using the public key of the receiver. 
Only the receiver has access to the re- 
ceiver's private key, which the receiver 
uses to decrypt the secure symmetric key, 
which, in turn, the receiver uses to de- 
crypt the message. "Public-key infra- 
structure" refers to the use of both en- 
cryption and digital signatures. 

IMPLEMENTATION ISSUES 

Encryption is available as an off-the- 
shelf technology, and vendors often pro- 
vide it as C code (sometimes as source 
code) or as a core for or already within 
ICs. In either case, evaluating encryption 
implementations can be challenging: The 
algorithm may be strong, and the demo 
may run like a champ, but just how secure 
is the implementation? You can't easily 
tell by looking at the outside of a chip or 
at complex code. Attackers are ruthless 
and attempt to create faults in whatever 
ways they can. For example, attackers 
may not answer questions nicely, instead 
bombarding a system with thousands of 
answers when the system requires only 
one and trying to blow a buffer (over- 
flow) or cause a boundary error that the 



RANDOMNESS" IS NEXT TO "SECRETNESS" 



Random numbers are critical in 
generating difficult-to-break 
keys. Simple pseudorandom- 
number generators (PRNGs), 
however, generate repeatable 
pseudorandom sequences and 
therefore repeatable sequences 
of keys. Thus, an attacker with 
the right initial seed could theo- 
retically generate the same 
sequence of keys and thus 
reduce the search space of keys 
to a trivial size for both past and 
future messages. 

Computers tend to be highly 
predictable, which makes them 
useful for computation but poor 
for generating true random 



numbers. For example, if the 
system clock updates only 17 
times/sec, knowing the approxi- 
mate rime someone generates a 
key reduces the unpredictability 
of seeds based on the system 
clock. In general, system values 
are not secure, because an 
unscrupulous user could access 
or guess the state of the system 
at the time of key generation, 
compromising the anonymity of 
the key. Even system characteris- 
tics that seem random, such as 
disk access and process and 
thread events, might have a 
hardware or software correlation 
that makes them predictable. A 



random number must come 
from a source outside the com- 
puter, preferably from several 
mixed sources that are unavail- 
able to potential attackers. 
Typical sources include micro- 
phone inputs, a user who is ran- 
domly striking keys, and temper- 
ature variations. Some of these 
sources, however, may still offer 
significant predictability, such as 
a user who repeatedly strikes 
the same key. The source must 
also supply enough entropy 
(unpredictable detail) to meet 
your volume of keys; generating 
3 256-bit key with only 160 ran- 
dom bits misses the point. 



In addition to beginning with 
a truly random seed, a secure 
PRNC should treat every seed 
bit equally so that no bit affects 
the output more than any other. 
The PRNC should also maintain 
a large internal state, making it 
difficult to predict or track future 
states and protect the generator 
state with the same level of 
security as a key. If an attacker 
can compromise and view the 
internal state of the generator, 



seeding ensure that the next 
output is impossible to deter- 
mine with confidence. 
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system is unprepared to handle. At- 
tackers search out vul- 
nerabilities, such as ar- 
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eas in which sensitive information 
resides or how such information is 
shared. For example, a poor pseu- 
dorandom-number generator can 
unintentionally generate weak keys 
(see sidebar "Randomness" is next 
to "secretness"). "Invalid" or "mis- 
informed" data can cause errors in 
trusted code. You can often avoid 
such errors by clearly defining 
data-input limits and lengths and 
by parsing all data through cen- 
tralized validation checks (versus 
checks scattered throughout the 
code). 

Another important difference 
among implementations is the 
packaging of the algorithm. A de- 
velopment kit for both hardware 
and software with a functional ap- 
plication-programming interface, 
clear documentation, and code ex- 
amples can be worth much more 
than you pay for them in time-to-mar- 
ket savings. Many encryption companies 
offer engineering services, acknowledg- 
ing that there is more to overall system se- 
curity than the encryption algorithm it- 
self. You can purchase various levels of 
encryption from base data encryption to 
"complete" implementations, which in- 
clude digital signatures, certificate-au- 
thentication management, and support 
for smart cards. 

Code and memory size (footprint) re- 
quire a careful look. Many algorithms 
take the form of C source code — not as- 
sembly — for platform portability. When 
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Using asymmetric encryption, the sender uses the receiver's public key to 
encrypt, and the receiver uses a private key to decrypt. Exchanging keys 
requires no secure channel. This method ensures that a reply is from the 
receiver because only the receiver has access to the private key. 



you evaluate an implementation, try to 
compile the code using several compilers; 
the compiler you use can significantly af- 
fect encryption speed, based on how it 
handles shifting operations. Also, con- 
sider how efficiently the algorithm is cod- 
ed. Because the bulk of encryption in- 
volves many loops, loop unrolling can 
significantly increase performance, al- 
lowing you to balance the specification of 
a high-performance processor and more 
memory. 

If you need to interface to other sys- 
tems and therefore other implementa- 
tions of the same algorithm, proper im- 



plementation is impor- 
tant for preventing in- 
teroperability vulnera- 
bilities. You can run 
your own validation 
tests, including the 
public tools manufac- 
turers usually create 
when the industry 
adopts a standard. 
These tools pass test 
vectors through the 
implementation and 
compare the encrypted 
output with reference 
vectors. Additionally, 
remember that, al- 
though the algorithms 
themselves may be 
free, their implementa- 
tions aren't. Having 
to license three algo- 
rithms—symmetric, 
asymmetric, and 
hash — -increases costs, 
and you may have to li- 
cense more than one of each to maintain 
legacy compatibility. Finally, be aware 
that export laws for encryption are com- 
plex and strict (see sidebar "Exporting 
encryption technologies"). 

WHERE DOES ENCRYPTION RESIDE? 

Encryption can reside in many areas in 
a system. In a virtual private network 
(VPN), for example, encryption can re- 
side in the router chip, on the router 
board, or at the application level. If you 
design routers, you may not even need to 
add encryption yourself; you can bundle 
someone else's software with your board 
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Much misinformation exists 
regarding US encryption-expor- 
tation policy. Previous, "back- 
door" policy allowed the export 
of encryption technologies that 
support keys as long as 56 bits 
if the technologies added key- 
recovery mechanisms. US policy 
has since removed the back- 
door restriction. Currently; US 
companies can export encryp- 
tion technologies that support 
keys as long as 56 bits except to 



embargoed countries without a 
license but after a one-time 
technical review or license 
exception. 

Algorithms that use keys 
longer than r >6 bits require a 
license, and you can export 
encryption technologies that 
support keys as long as 64 bits 
for certain mass-market prod- 
ucts. Foreign subsidiaries and 
such industries as financial, 
health, and medical, may be 



able to export to other countries 
for their use. This situation has 
opened the door for US compa- 
nies to purchase US encryption 
products and use them in for- 
eign countries, but this situation 
still does not address the desire 
of US OEMs to sell to foreign 
companies. US encryption com- 
panies face a challenge: Foreign 
companies have access to the 
same encryption ideas and algo- 
rithms but aren't bound by US 



regulations and can sometimes 
sell to anyone in the world, giv- 
ing them a competitive advan- 
tage. For strong encryption, it 
may make sense for multina- 
tional companies to buy outside 
the United States. For the latest 
updates on what's legal, visit the 
Bureau of the US Department of 
Commerce's Bureau of Export 
Administration's Web site at 
www.bxa.doc.gov/. 
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and avoid that part of the 
design. You can also add 
encryption as 
an external 
box or accelerator card 
for use with legacy 
equipment; placed in 
line before the router, the 
box transparently en- 
crypts or decrypts infor- 
mation going to or com- 
ing from the router. 

Employing encryption 
in hardware offers 
greater internal security 
and encryption speeds 
than software but offers 
less flexibility for mass 
redeployment or up- 
grades. You might con- 
sider a programmable 
approach in which you 
can later reconfigure the 
encryption engine, but 
such a system offers a 
new vulnerability: An attacker can pos- 
sibly reprogram the engine and gain ac- 
cess to all messages passing through the 
engine. 

In addition to protecting information 
that passes through a device, encryption 
can protect a system from viruses — ma- 
licious data intended to crash a system 
(for example, an invalid MPEG stream). 
It can also protect against "spoofing" 
(someone pretending to be a trusted 
source) and "man-in-the-middle mas- 
querading" (for example, tricking a 
browser into viewing modified Web 
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Using a digital signature or digital envelope, asymmetric encryption provides a 
secure channel to exchange a symmetric secret key by encrypting the secret key 
using the receiver's public key. 



pages). Another example is a Java set-top 
box, which you may configure to allow 
on-the-fly reprogramming. An attacker 
could bypass pay-per-view restrictions or 
infect a network of boxes with a virus by 
"updating" internal code. By requiring 
digitally signed and encrypted code up- 
dates, you make such an attack more dif- 
ficult. For third parties writing software 
for your final platform, digital signatures 
tell you who sent an update and guaran- 
tee that no one has altered the code, but 
they do not ensure that the code is with- 
out errors or that it is not infected with 



a virus. Your platform 
must be bulletproof 
against all code that an 
attacker could possibly 
download. 

System-bandwidth re- 
quirements can affect the 
placement of encryption. 
Employing software on a 
router can significantly 
reduce the throughput of 
the router because of the 
increased processing 
overhead dedicated to 
encryption. If you change 
keys with every transac- 
tion, you may slow 
throughput by being un- 
able to generate a high 
enough volume of keys 
fast enough or by taking 
too long to access keys. If 
bandwidth is tight, you 
may want to reduce the 
size of a key by selecting a 
different standard, such as a 160-bit el- 
liptic key instead of a 1024-bit RSA key. 

CLOAK-AND-DAGGER ATTACKS 

The hybrid schemehas several vulner- 
abilities. For example, the receiver must 
be able to verify that no one has tam- 
pered with the message. Hash functions, 
such as MD5, provide one-way encryp- 
tion of a message or the equivalent of a 
complex checksum. Both sides perform 
the hash; the sender encrypts the hash 
value with the symmetric key. And, if the 
results match, you can confidently as- 
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Compression: Brute-force 
attacks assume that the decrypt- 
ed message is obviously a mes- 
sage; that is, it has some telltale 
signature or pattern, such as 
"The secret message is:." Such a 
pattern may not be uncommon; 
for example, all credit-card trans- 
actions may begin with the 
same header to indicate the type 
of transaction. By removing the 
pattern from the message 
before the sender encrypts it, an 
electronic cracker has more diffi- 
culty determining that it has 



found a valid message and thus 
the right key. Thus, compressing 
messages and keys in digital 
envelopes before encryption 
offers another layer of protec- 
tion. A similar method, which 
Tripie-DES (Triple-Data 
Encryption Standard) uses, 
encrypts the message more than 
once in succession. 

Steganography: Steg- 
anography, or data hiding, 
buries valuable information with- 
in less valuable or decoy infor- 
mation, taking advantage of the 



fact that messages, files, and 
data often contain unused and 
padded or insignificant areas. 
For example, streaming video 
could contain set-top-box com- 
mands invisible to the viewer. 
One advantage of steganogra- 
phy is that a successful attacker 
may not know that the data con- 
tains a hidden message. 

Cognometrics: Password gen- 
eration has come a long way 
from using an easily accessible 
social-security number. Cogno- 
metrics offers a creative means 



for "remembering" a password, 
such as using pictures instead of 
alphanumeric characters or ask- 
ing a battery of preanswered 
questions to which only one 
person would know all of the 
"correct" answers (for example, 
the question, "What is your 
favorite beer?" and the answer, 
"The kind in my refrigerator"). 
Methods such as cognometrics 
also prevent attackers from 
using a password in another, 
less secure environment. 
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sume that no one has altered the message. 

Another vulnerability is authentica- 
tion: The receiver needs to know that the 
other party is indeed the right party and 
not a spoofer. Verifying the identity of the 
sender is fairly straightforward: The 
sender encrypts an identification (ID) 
message using the sender's private key, 
and the receiver decrypts it using the 
senders public key. (Communicators 
should use an ID message only once to 
prevent a spoofer from using it later.) A 
new problem arises: The public keys must 
come from a trustworthy source. A hack- 
er can access keys posted on a Web page 
and replace the receiver's public key with 
the hacker's own. This problem presents 
the man-in-the-middle attack, in which 
a sender encrypts a message using the at- 
tacker's public key. The attacker inter- 
cepts and decrypts the message and then 
encrypts it using the receiver's public key 
and passes the message on to the receiv- 
er. The result is that neither party knows 
that an attacker has intercepted or com- 
promised the message. To answer this 
need, "certifying authorities" provide cer- 
tificates containing public (nowsemipri- 
vate) keys in a secure fashion using the 
certifying authority's private key. But at- 
tackers can break certifying-authority 
keys, forcing the certifying authority to 
revoke the certificates. 

And so on. Encryption involves a lot of 
cloak-and-dagger, and attacks can be 
complex and subtle. For every preventive 
measure, a corresponding countermeas- 
ure exists. How careful your implemen- 
tation needs to be depends on the calcu- 
lated risk of data loss. In any case, keeping 
public keys relatively secret and fre- 
quently changing them should be an in- 
tegral part of a system's design, but don't 



count on the secrecy to protect them! At- 
tackers can compromise or guess secrets. 
If you don't employ a third party as a cer- 
tifying authority, you take on the role 
yourself and need to manage access to 
your public keys. 

KEY MANAGEMENT 

The value of a key is directly propor- 
tional to the value of the information it 
protects. If one key protects an entire sys- 
tem, cracking that one key is worth every- 
thing in the system. If one key protects 
one user, cracking the key is worth the in- 
formation available to that user. A key 
that protects only one transaction is 
worth the least in cost versus value gained 
and thus offers the best protection. How- 
ever, using a key requires a rigorous key 
management, adding complexity to a sys- 
tem and opening another door to attack. 

An important foundation for key man- 
agement is that the cryptoengine auto- 
matically generates, exchanges, uses, and 
discards keys without human interven- 
tion. In this way, a human can never ac- 
cess a private key, ensuring that no one 
can copy, misuse, or give away the key. 
Tamperproof containers should "zero 
out" a key if anyone ever compromises 
the container. There should be no exter- 
nal access to the memory holding a key 
or to the memory bus. Protecting keys 
outside a tamperproof container may be 
more difficult than you think. For exam- 
ple, a key hidden on a network may reside 
in more than one place: temporarily in a 
cache, in a recently freed memory allo- 
cation (memory-reconstruction attack), 
or in the discarded shell of a deleted file. 

You must also support a mechanism 
for revoking keys. This feature becomes 
necessary if someone compromises a key; 



that is, the key breaks or the person hold- 
ing the key becomes untrusteci (for ex- 
ample, fired). One method is to maintain 
a list of revoked keys. In a limited-re- 
source environment such as a set-top 
box, however, you can record only so 
many revocations before either the buffer 
blows or older revocations fall off the list, 
thus reinstantiating those revoked keys. 
Using a certifying-authority model 
avoids these vulnerabilities. 

TOKENS AND PASSWORDS 

Secure systems may use a mix of ways 
to verify the identity of a user: The veri- 
fication can be from something you have, 
such as a token, smart card, or PCMCIA 
card; something you are, using biomet- 
rics for fingerprint, voice, face, or other 
forms of recognition; or something you 
know, such as a password. 

The "poster child" for tokens and se- 
cure key packaging is the smart card. A 
cryptoengine inside the smart card is iso- 
lated from the rest of the system, and at- 
tackers cannot easily compromise it. Be- 
cause the processor and memory reside 
on the same chip, the key never travels 
over an external bus that is vulnerable to 
observation. You don't have to use smart- 
card chips in a smart card. A set-top box, 
for example, could use a smart-card chip 
to implement secure key generation, stor- 
age, and limited decryption. 

Tokens should be impossible to forge 
and should be attached to one user to 
prevent their use when stolen. Biometric 
methods tie a token to a user on a physi- 
cal level (fingerprint), and passwords do 
so based on a user's knowledge. Howev- 
er, passwords without tokens are inse- 
cure; after all, a computer can crack any 
password that a person can remember. 



POTENTIAL APPLICATIONS REQUIRING ENCRYPTION 


Application 

Virtual private network (VPN) 


Attack 

System exposed; insecure Internet 
used as backbone for secure intranet 


Standard 

IPSEC 


Role of encryption 

Creates secure data channel, 
transparent to applications 


Bridges, for example, between 
applications and the lower, more 
vulnerable levels of the network 


Snooper application accessing data 
from other applications 


Secure-sockets-layer 
(SSL) protocol 


Protects system from 
unintended access 


Bar-top computer game 


System exposed; wireless 
capture of data 


DES for transfer to 
credit-card companies 


Protects credit-card numbers 
sent wirelessly to back-room 
server for processing 


Set-top bo* or Internet appliance 


Pirate box 


Various 


Controls Internet/interactive 
services or prepaid premium viewing 


Digital security camera 


Must physically compromise internal 
network; for example, wire splicing 


Closed networks; 
no standards 


Prevents "nothing's happening" 
signal from being spoofed over real 
signal 
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Also, a strong key protected solely by a 
password is only as secure as the weaker 
password. 

Note that smart cards are vulnerable; 
attacks based on differential power analy- 
sis can provide attackers with informa- 
tion on the internal state of the smart 
card (Reference 3). Proposed changes to 
prevent attackers from "reading" smart 
cards or other ICs through such infor- 
mation leaks include current scrambling, 
which breaks up current patterns by in- 
serting extra and random wait states so 
that patterns are more difficult to catch, 
and reducing variances in internal cur- 
rents so that internal states are pm 
more difficult to determine. 
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Despite all the precautions 
you can take to prevent the 
compromise of your encryp- 
tion system, you should as- 
sume that someone can and 
will break your encryption 
scheme. If an attacker discov- 
ers a backdoor, flaw, or vulnerability, you 
need to be able to recover and correct it. 

The first step is determining whether 
someone has breached your system. If the 
attacker's motive is to damage or crash 
your system, you'll probably quickly find 
out this fact. However, if the attacker 
wants information only to use it else- 
where, such as with credit-card numbers, 
or to abuse a function, such as adding val- 
ue to a smart card, no fireworks point out 
these attacks. Filters can uncover this sec- 
ond kind of breach by observing system 
behavior and watching for aberrations, 
such as a smart-card account making an 
unusual number of transactions. 

Another method for detecting a breach 
is to keep a log of every transaction. In a 
set-top environment, only the home of- 
fice should ever communicate with a 
node box. Therefore, if the transaction 
logs fail to match, then someone has at- 
tempted to contact the node, signaling 
that someone may have compromised the 
node. The more information you can 
capture, the better your chances of track- 
ing and understanding a breach. The 
problem arises, however, that an attacker 
can use any debugging hooks you include 
in the final product to compromise it. 

WHEN IS "GOOD ENOUGH" GOOD ENOUGH? 

The foundation of a good security 
scheme is that the cost to steal informa- 
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tion should be more than the informa- 
tion is worth. Remember also that en- 
cryption works in parallel with physical 
protection: An attacker needs to break 
both to steal information. If someone has 
access to your encrypted data, then the 
attacker has already compromised your 
system. Encryption is managing the com- 
promise by placing another barrier in the 
path of an attacker before the attacker can 
abuse the information. Some systems 
have built-in physical protection; set-top 
boxes connect to conditional-access lines 
that already protect content. A VPN, 
however, uses access lines and the Inter- 
net, which offer little or no pro- 
tection. Encryption is about trust 
and preventing access to those 
without trust. Security offers the 
best results when employing a 
combination of countermeas- 
ures. 

Encryption may seem a trifle 
overdone. Cryptography tends 
to predict the worst to prevent 
surprises. Secure encryption, 
therefore, must balance protection, ac- 
cess, performance, risk, and cost in the 
pursuit of "sufficient security." One reli- 
able metric is that the more complicated 
your implementation, the more vulner- 
able it is. Aim for simplicity, and the rest 
should follow, o 
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